There's an inconsistency in how the note field is accessed compared to the priority field. The synthesizer stores both priority and note in auth.Attributes, but here note is being read from auth.Metadata. While this might work in some cases because Metadata is also populated from the file, it's better to have a single, consistent source for these synthesized values.

For consistency and correctness, note should be read from auth.Attributes, just like priority. This also has the benefit of removing a redundant strings.TrimSpace call, as the synthesizer already handles trimming.

	// Expose note from Attributes (set by synthesizer from JSON "note" field).
	if note := authAttribute(auth, "note"); note != "" {
		entry["note"] = note
	}

The expression strings.TrimSpace(nv.String()) is evaluated twice here, once in the condition and again in the assignment. This is slightly inefficient. You can improve this by storing the trimmed string in a variable and using it in both places. This will also make the code a bit more readable.

if nv := gjson.GetBytes(data, "note"); nv.Exists() {
	if trimmed := strings.TrimSpace(nv.String()); trimmed != "" {
		fileData["note"] = trimmed
	}
}

This block for handling req.Note is very similar to the block for req.Priority just above it. This introduces code duplication, specifically the check if targetAuth.Metadata == nil.

Consider refactoring to reduce this duplication and improve maintainability. You could combine the logic by first checking if either field needs to be updated, then initializing the metadata map if needed, and then handling each field.

For example:

	if req.Priority != nil || req.Note != nil {
		if targetAuth.Metadata == nil {
			targetAuth.Metadata = make(map[string]any)
		}

		if req.Priority != nil {
			if *req.Priority == 0 {
				delete(targetAuth.Metadata, "priority")
			} else {
				targetAuth.Metadata["priority"] = *req.Priority
			}
		}
		if req.Note != nil {
			trimmedNote := strings.TrimSpace(*req.Note)
			if trimmedNote == "" {
				delete(targetAuth.Metadata, "note")
			} else {
				targetAuth.Metadata["note"] = trimmedNote
			}
		}
		changed = true
	}

Ignore invalid disk priority values instead of coercing to 0

When the auth manager is unavailable, the fallback path now emits priority for any file that merely has a priority key, but gjson.Int() coerces non-numeric values (for example "priority":"high" or "priority":null) to 0. This makes the API report a concrete priority that was never configured and can change sort/order behavior in degraded mode, while the normal in-memory path only includes priority when integer parsing succeeds.

Useful? React with 👍 / 👎.

Read list fields from metadata when attributes are missing

buildAuthFileEntry now exposes priority/note only from auth.Attributes, but registerAuthFromFile still initializes attributes with just path/source and leaves these values in Metadata; as a result, files added via UploadAuthFile can contain valid priority/note in JSON yet GET /auth-files omits them until some later re-synthesis repopulates attributes. This makes the new response fields unreliable in normal auth-manager mode for uploaded or freshly registered files.

Useful? React with 👍 / 👎.

Emit note only for string-valued JSON fields

In the auth-manager fallback path, note is read with nv.String() for any existing JSON value and then trimmed, so malformed auth files like {"note":123} or {"note":true} get exposed as concrete note text instead of being ignored. This diverges from the normal manager path (synthesizeFileAuths/buildAuthFileEntry), which only accepts string notes, so degraded mode can return inconsistent and misleading note values. Restrict this branch to gjson.String before setting fileData["note"].

Useful? React with 👍 / 👎.